In communications between two devices, flow control is used to manage the pacing of data transmission between the devices to prevent a fast transmitter from outrunning a slow receiver by sending too much data too quickly. It provides a mechanism for the receiver to control the transmission speed, so that the receiver is not overwhelmed with data from transmitter. Flow control mechanisms can in general be categorised according to whether or not the receiver sends feedback to the transmitter. Various types of flow control mechanisms provide for error detection and correction. For example, for reliable communication in which it is desired to ensure that all necessary packets of data are correctly received at the receiver, an acknowledgement of one type or another may be sent by the receiver to the transmitter. For example, with positive acknowledgement (often termed ACK in some applications), the receiver explicitly notifies the transmitter which packets, messages, or segments were received correctly. With negative acknowledgment (often termed NACK in some applications), the receiver explicitly notifies the transmitter which packets, messages, or segments were not received or were received incorrectly and thus may need to be retransmitted. Variations of these basic techniques are known and used in various transmission protocols. On the other hand, in unacknowledged mode (often termed UM in some applications), there is no feedback from the receiver to the transmitter of which data packets, etc. have or have not been received.
As particular examples, Technical Specification TS 25.322 of the 3GPP (Third Generation Partnership Project) provides a specification for Acknowledge Mode Radio Link Control (AM RLC) and Unacknowledge Mode Radio Link Control (UM RLC) in wireless devices. In general, the term “wireless devices” used in this specification includes in general any device capable of connecting wirelessly to a network, and includes in particular mobile devices including mobile or cell phones (including so-called “smart phones”), data cards, USB dongles, personal digital assistants, pagers, tablet and laptop computers, content-consumption or generation devices (for music and/or video for example), etc., as well as fixed or more static devices, such as personal computers, game consoles and other generally static entertainment devices, various other domestic and non-domestic machines and devices, etc. The term “user equipment” is often used to refer to wireless devices in general, and particularly mobile wireless devices.
AM (Acknowledge Mode) RLC has the following functionality:
1. AM RLC consists of a transmitter RLC entity and a receiver RLC entity.
2. The transmitter RLC entity of one device (e.g. a network “base station”, Node B, etc.) transmits RLC PDUs (protocol data units) to the other device (in this example, a user equipment or “UE”) and the receiver RLC entity of the other device receives RLC PDUs.
3. If ciphering is configured, then the transmitter RLC entity ciphers the transmission RLC PDUs and the receiver RLC entity deciphers the received RLC PDUs.
4. The receiver RLC entity positively acknowledges or negatively acknowledges the receipt of RLC PDUs by sending a corresponding ACK or NACK status RLC PDU to the transmitter RLC entity.
5. The transmitter RLC entity updates a transmission window upon receipt of positive-acknowledgement ACK for the RLC PDUs that have been received by the receiver RLC entity. On the other hand, the transmitter RLC entity retransmits the negative-acknowledged RLC PDUs reported by the NACK status RLC PDUs.
A so-called service data unit (SDU) is typically segmented to form a group of RLC PDUs, which in this context are packets of data to be individually transmitted. Here, they are also referred to as AMD PDUs (Acknowledged Mode Data PDUs). The transmitter keeps a note of the group of RLC PDUs that need to be transmitted and acknowledged in the form of a transmission window, which allows control of the number of RLC PDUs being sent by the transmitter to the receiver to avoid causing a receiving buffer at the receiver to overflow. If the transmitter receives a positive acknowledgement of receipt of a particular RLC PDU from the receiver, the transmitter can update the transmission window by removing the record of that RLC PDU and adding a record of a new RLC PDU to be transmitted. From the sequentially numbered field (the SN) of the headers of the RLC PDUs, the receiver can know if particular RLC PDUs should have been received but are missing and report back accordingly to the transmitter entity, which can then retransmit the missing RLC PDUs. To support these autonomous retransmissions, a transmitter using AM RLC needs to buffer the transmitted RLC PDUs until they are positively acknowledged by the receiver RLC so that it can retransmit them if necessary, and therefore requires some data buffer in the form of hardware memory for storing the RLC PDUs of the current transmission window. Similarly, the receiver needs a buffer to store successfully received RLC PDUs for later concatenation with any retransmitted RLC PDUs. In general, AM RLC is used for data communication that requires reliability (e.g. signalling connection, FTP (File Transfer Protocol), HTTP (Hyper Text Transfer Protocol), etc.).
UM (Unacknowledge Mode) RLC has the following functionality:
1. UM RLC consists of a transmitter RLC entity and a receiver RLC entity.
2. The transmitter RLC entity transmits RLC PDUs and the receiver RLC entity receives RLC PDUs.
3. If ciphering is configured, then the transmitter RLC entity ciphers the transmission RLC PDUs and the receiver RLC entity deciphers the received RLC PDUs.
4. Ack/Nack information is not exchanged between the receiver and transmitter RLC entities. Accordingly, the transmitter RLC entity sends RLC PDUs whenever the data and the data transfer resource are available.
Notably, UM RLC does not require the transmitter or the receiver to have a buffer for storing data packets that are being transmitted as there is no retransmission of data packets (i.e. RLC PDUs in this example) that have not been received by the receiver. However, UM RLC has a serious problem that in that ciphering de-synchronisation may occur. In particular, when the transmitter ciphers the individual PDUs and transmits them, it keeps track of this by use of an incremental HFN (Hyper Frame Number), and the receiver operates similarly on receipt of the ciphered PDUs. However, if PDUs are not received by the receiver, the count maintained by the receiver gets out of step with the count used by the transmitter as they are operating independently and correct deciphering becomes impossible. UM RLC is used for real-time services, such as video and/or audio streaming services or CS voice service (for a CSoHSPA (Circuit Switched Call over a High Speed Packet Access Network) case).
Thus, conventional acknowledged mode has a problem in that it requires a relatively large hardware memory buffer at the transmitter and the receiver for storing data packets that are to be transmitted, whereas conventional unacknowledged mode has a problem in that it does not guarantee delivery of data and also leads to disrupted decryption of encrypted data if data packets are not safely received at the receiver. Both of these different problems variously inhibit developments in wireless technology.